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ABSTRACT 


--  •  - 


A  new  measure  of  complexity  is  introduced,  one  which  describes  a  flow¬ 
chart  by  a  polynomial.  This  measure  takes  both  the  elements  of  the  flow  chart 
and  its  structure  into  account. 

Rules  are  given  for  obtaining  the  polynomials  for  various  flowcharts,  such 
as  structured,  unstructured,  with  loops,  and  with  simple  or  multiple  selectors 
(i.e.,  CASE  statements).  The  polynomial  measure  allows  the  comparison  of 
alternate  designs  and  tells  how  to  divide  a  program  into  modules  for  minimal 
overall  complexity.  The  measure  also  gives  the  number  of  path  tests  and 
bounds  on  cyclomatic  complexity.  Finally  a  comparison  is  made  of  this  measure 
with  several  other  popular  complexity  measures. 
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1.0  INTRODUCTION 

A  problem  of  interest  in  software  engineering  is  the  measuring  of  program 
complexity . 

Complexity  is  a  fuzzy  and  an  ill  defined  concept,  generally  meaning  that 
the  program  is  "complicated"  [1].  It  is  perceived  that  it  is  this  "complication" 
which  reduces  a  programmer's  productivity  from  say  20  statements/day  on  job 
A  to  just  5  statements/day  on  job  B .  We  perceive  that  it  is  the  higher 
complexity  nf  job  B  which  accounts  for  this  diminished  productivity. 

An  accepted  measure  of  complexity  will  allow  to  compare  programs.  One 
important  application  could  be  the  measurement  of  complexities  of  alternate 
designs  and  the  selection  of  the  design  with  the  lowest  complexity. 

There  have  been  several  attempts  to  quantify  precisely  the  notion  of 
complexity.  Typically  a  countable  property  of  a  program  is  identified,  and  the 
count  is  defined  as  the  complexity  [1].  The  control  flow,  in  particular,  has 
been  a  subject  of  extensive  scrutiny.  One  example  of  such  a  measure  is  the 
cyclomatic  number  [2]  counting  the  number  of  regions  in  a  graph,  and  related 
to  the  number  of  deciders  in  the  program. 

The  polynomial  measure  introduced  here  also  arises  from  the  properties  of 
the  control  flow.  It  is  quantitative,  objective,  and  relatively  simple  to  obtain. 
It  tells  about  the  structure  of  a  program,  and  in  fact  allows  the  construction  of 
a  flowchart  from  the  measure.  It  is  related  to  the  testing  effort.  Because  it  is 
the  testing  which  consumes  most  labor,  a  measure  related  to  testing  reflects 
the  total  labor  needed  to  produce  the  program. 

2.0  THE  STATE  OF  THE  ART  -  A  BRIEF  REVIEW 

Several  measures  of  complexity  have  been  introduced  in  the  recent  lit¬ 
erature.  We  will  briefly  review  several  of  the  measures  and  their  derivatives. 

2.1  Complexity  Based  Upon  Features  of  the  Program  [3]. 

Such  measure  counts  the  number  of  certain  features  of  a  program  (for 
example,  the  number  of  IFs),  and  compares  them  with  the  number  of  same 
features  in  a  "reference"  program.  The  reference  program  is  to  be  either 
given  in  an  installation  or  obtained  by  averaging  a  group  of  programs. 
Different  users  may  obtain  different  complexity  measures  by  this  technique, 
and  as  stated  the  measure  only  records  the  number  of  features  and  not  their 
role  in  the  program  structure. 

2.2  Complexity  Based  Upon  Operator  and  Operand  Counts 

Halstead  [4]  derived  several  measures  from  the  counts  of  distinct  oper¬ 
ators  and  operands  in  a  program,  and  from  the  frequencies  of  each  operator 
and  each  operand.  He  obtained  an  expression  for  the  size  of  the  implementing 
algorithm  (called  the  program  volume),  and  for  the  total  number  of  mental 
discriminations  needed  to  generate  the  program  (called  the  program  effort). 
Similar  results  were  obtained  by  Shooman  and  Laemmel  [5]  in  their  study  of 
Zipf's  laws  of  natural  languages. 
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2 . 3  Complexity  as  the  Difficulty  Experienced  in  Understanding  a  Piece 
of  Software  [6,7 ]~ 

This  complexity,  also  referred  as  psychological  complexity,  is  viewed  as 
a  separate  area  from  the  quantitative  computational  complexity.  Curtis  et  al. 
[6]  describe  experiments  to  determine  which  software  characteristics  affect 
understanding. 

2.4  Control  Flow  Complexity 

The  geometry  of  the  control  flow  graph  has  been  studied  by  several 
workers.  This  graph  has  twin  advantages  over  the  program  itself:  (1)  it 
displays  the  control  flow  graphically  and  thus  more  clearly  than  the  program 
does,  and  (2)  omits  the  particulars  of  the  implementing  algorithm,  thus 
reducing  the  level  of  detail.  It  is  believed  by  many  (including  this  author) 
that  "the  secret  of  complexity"  resides  in  the  control  flow  graph,  ready  to 
be  detected  by  a  sufficiently  clever  detective.  Up  to  date  the  researchers 
studied  a  countable  property  of  the  control  graph  and  used  the  resulting 
number  as  measure  of  complexity. 

2.4.1  The  Cyclomatic  Complexity  Measure  [2j. 

The  cyclomatic  measure  gives  The  complexity  as  e-r;t-2p  wl  "re  e  is  the 
number  of  edges,  n  the  number  ci  nodes  and  p  the  number  r!k  connected 
components  (i.e.,  the  number  of  flowcharts).  For  example,  a  program  with 
two  called  subroutines  (requiring  one  flowchart  for  the  program  and  two 
flowcharts  for  the  subroutines)  having  13  total  edges  and  13  total  nodes  has 
the  cyclomatic  complexity 


V  =  13  -  13  +  2*3  =  6 

For  single-flowchart  programs  a  simplification  leads  to  V  =  n+] ,  where  7t 
is  the  number  of  decisions.  Geometrically  the  cyclomatic  complexity  can  be 
interpreted  as  the  number  of  regions  formed  by  the  control  flow  graph. 

2.4.2  Extended  Cyclomatic  Measures. 

Myers  [8]  takes  into  account  the  additional  complexity  of  compound 
conditions.  His  measure  replaces  the  cyclomatic  number  by  2  numbers,  with 
the  first  number  being  the  cyclomatic  number  as  before,  and  the  second 
number  being  the  number  of  conditions  plus  one.  Then  for  example,  the 
statement, 

IF  X>3  &  Y<4  THEN. .  . 

ELSE. . . 

has  the  cyclometric  complexity  of  2  (because  tt=1  and  p=l)  and  the  extended 
complexity  of  2:3  (because  there  are  2  conditions). 

Basili  and  Reiter  [9]  examined  four  variations  in  determining  cyclomatic 
complexity,  involving  from  different  weighting  of  CASE  statements  and  com¬ 
pound  predicates.  The  lirst  variation  is  the  original  cyclomatic  number.  In 
the  second  variation  each  condition  in  a  compound  predicate  contributes  a 
unit  to  the  cyclomatic  number.  In  the  third  variation  a  compound  condition 
still  counts  as  a  single  unit,  but  each  CASE  statement  of  n  alternatives 
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contributes  floor [log2(n)J  units1  to  the  cyclomatic  number  (in  the  first  2 
variations  such  a  CASE  statement  contributes  n  units  to  the  cyclomatic 
number).  In  the  fourth  variation  each  condition  in  a  compound  predicate  is 
counted  and  the  CASE  statement  contributes  logarithmically  as  in  the  fourth 
variation . 

2.4.3  Maximal  Intersection  Number  (MIN)  [10]. 

This  measure  is  derived  from  the  control  graph  by  drawing  a  line 
through  it  and  counting  the  maximal  number  of  intersections  (MIN).  If  the 
graph  is  made  up  of  substructures  in  sequence,  this  number  is  obtained  as 
the  sum  of  MINS  of  all  subparts  -  2*number  of  subparts  +  2. 

2.4.4  The  "Knots11  Complexity  [11]. 

Here  we  count  the  intersections  (i.e.,  knots)  of  the  control  graph 
flowlines.  Since  structured  programs  have  no  intersections,  they  have  zero 
knots.  Hence,  the  knots  are  a  measure  of  unstructuredness  rather  than 
complexity. 

2.4.5  A  Comparison  of  Measures  of  Control  Flow  Complexity  [12] 

In  a  recent  article  a  comparison  was  made  of  three  measures,  the 
Halstead  program  effort,  the  cyclomatic,  and  the  knots.  The  authors  (A.L. 
Baker  and  S.H.  Zweben)  list  several  weaknesses  of  the  knots.  They  con¬ 
clude  that  single  number  characterization  is  inadequate,  and  thus  more 
research  is  needed  to  capture  the  control  flow  complexity. 

3.0  WHY  IS  THE  PROGRAM  STRUCTURE  IMPORTANT? 

Observe  that  the  measures  just  reviewed  count  a  property  of  the  con¬ 
trol  flow  geometry.  The  cyclomatic  counts  regions,  the  MIN  counts  maximal 
possible  intersections,  the  knots  counts  intersections  of  flowlines.  None  of 
these  measures  take  the  program  structure  into  account.  For  example,  in 
the  cyclometric  measure  V=n+1,  only  the  number  of  deciders  matters,  and  not 
how  they  are  connected. 

To  see  that  connection  of  the  deciders,  that  is,  the  structure  of  the 
program,  has  an  important  influence  on  complexity  we  have  drawn  in  Fig.  1 
two  different  connections  of  3  deciders.  Since  a  major  part  of  program 
effort  goes  into  testing ,  we  argue  that  a  program  complexity  should  increase 
with  test  effort.  To  test  all  paths  of  the  program  segment  of  Fig.  1(a), 
four  tests  are  needed  to  cover  the  four  conditions 

A,  AB,  ABC,  ABC 

The  program  segment  of  Fig.  1(b)  has  8  paths.  Their  traversal  requires 
the  selection  of  eight  test  inputs  to  satisfy  the  eight  conditons 

ABC,  ABC,  ABC,  ABC,  ABC,  ABC,  ABC,  ABC 
and  thus  more  test  effort  than  the  one  of  Fig  la. 


1floor(x)  signifies  the  largest  integer  not  exceeding  x 


4.0  THE  POLYNOMIAL  MEASURE  OF  COMPLEXITY 


The  two  segments  of  Fig.  1  lead  to  the  conclusions: 

a.  each  decider  has  2  paths 

b.  the  sequential  connection  of  two  deciders  leads  to  22  paths 

c.  more  generally,  the  sequential  connection  of  n  deciders  leads  to  2n 
paths 

d.  the  parallel  connection  of  2  deciders  results  in  2+1  or  3  paths 

e.  the  parallel  connection  of  n  deciders  results  in  n+1  paths 

We  propose  to  denote  a  single  decider  by  the  variable  x,  as  shown  in 
Fig.  2.  Then  the  sequential  connection  of  two  deciders  is  denoted  by  x2 
(see  Fig.  3),  and  more  generally,  the  sequential  connection  of  n  deciders  by 

xn.  The  power  of  n  indicates  the  multiplicative  nature  of  the  program 
paths,  created  by  such  a  connection.  Thus,  for  example,  the  decider  con¬ 
nection  Fig .  3  has  22  program  paths ,  while  such  a  sequential  Connecticut  of  n 

deciders  gives  rise  to  2n  paths. 

Consider  next  the  connection  of  Fig  4.  This  connection  add.s  only  one 
path  to  the  x  decider,  and  can  be  described  by  x+1.  It  is  obvious  now  that 
a  combination  of  the  two  basic  connections  of  Figures  3  and  4  gives  rise  to 
polynomial  expressions.  As  an  example.  Fig.  5  portrays  a  2x  connection, 
while  Fig.  6  describes  an  x(x+l)  or  x2+x  situation. 

These  figures  can  be  simplified  by  replacing  each  decider  by  a  node 
and  all  sequential  statements  (shown  by  a  rectangular  box  in  the  figures)  by 
just  a  flowline.  Fig.  7  portrays  the  x  and  x2  situations.  Similarly,  the  x+1 
connection  of  Fig.  4  simplifies  to  the  one  shown  in  Fig.  8. 

5.0  OBTAINING  THE  POLYNOMIAL  FROM  THE  FLOWCHART  -  RULES  AND 

EXAMPLES 

Consider  again  the  simplified  flowchart  of  Fig.  8.  If  the  left  flowline  is 
drawn  on  the  right,  we  obtain  the  equivalent  representations,  shown  in  Fig. 
9,  all  portraying  the  x+1  connection. 

Fig.  5  can  be  redrawn  as  shown  in  Fig.  10,  showing  the  addition  of  the 
two  x  deciders.  Note  that  the  addition  requires  an  additional  decider  (that 
is,  an  additional  node).  More  generally,  if  there  are  two  flowcharts  de¬ 
scribed  by  the  polynomials  Pi(x)  and  p2(x),  then  the  parallel  connection  of 
these  two  flowcharts  (shown  in  Fig.  11)  is  described  by  px(x)  +  p2(x). 

The  rules  for  obtaining  a  polynomial  from  a  flowchart  can  now  be  formu¬ 
lated.  These  are: 

1.  A  flowchart  composed  from  two  parallel  flowcharts  (see  Fig.  11)  is 
described  by  the  sum  of  the  polynomials  for  each  component  flow¬ 
chart. 
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Fig.  1(a)  A  FOUR-TESTS 
CONNECTION 


Fig.  1(b)  AN  EIGHT-TESTS 
CONNECTION 


FIG.  1  TWO  DIFFERENT  CONNECTIONS  OF  THREE  DECIDERS 


AN  x+1  CONNECTION 


A  2x  CONNECTION 


.6  AN  X2  +  X  CONNECTION 
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FIG.  7(a) 

SIMPLIFIED 
REPRESENTATION  OF 
A  DECIDER 

FIG.  7  SIMPLIFIED  REPRESENTATIONS  OF  DECIDERS 


FIG.  7(b) 

AN  x2  CONNECTION 


FIG.  8  SIMPLIFIED  REPRESENTATION  OF  FIG.  4 
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2.  A  flowchart  composed  from  two  sequential  flowcharts  is  described 
by  the  product  of  the  polynomials  for  each  component  flowchart. 
This  situation  is  portrayed  in  Fig.  12. 

3.  The  basic  elements  of  a  flowchart  are  a  flowline  (characterized  by 
1)  and  a  decider  (characterized  by  x),  as  shown  in  Fig.  13. 

With  these  rules  we  shall  obtain  polynomials  for  several  examples.  For 
the  flowchart  of  Fig.  14  we  have  the  sequence  of  x+1  and  x+2.  Hence  this 
flowchart  is  described  by  (x+l)(x+2)  or  x2+3x+2.  For  the  flowchart  of  Fig. 
15,  x  is  paralleled  with  1  giving  x+1.  For  the  flowchart  of  Fig.  16,  x2  is 
paralleled  with  x  giving  x2+x. 

6.0  UNSTRUCTURED  PROGRAMS 

Up  to  now  all  the  examples  led  to  structured  programs  with  the  de¬ 
scribing  polynomial  obtained  from  inspection  of  the  flowchart.  We  will  now 
illustrate  how  to  obtain  the  polynomial  for  unstructured  programs. 

Observe  that  all  unstructured  program  can  be  converted  to  a  structured 
one  by  tracing  the  path  with  GO  TOs,  eliminating  the  GO  TOs,  and  duplicat¬ 
ing  the  code.  As  an  example,  consider  the  flowchart  of  Fig.  17  representing 
an  unstructed  program.  Note  that  the  conversion  shown  in  Fig.  18  trans¬ 
lates  into  the  PL/I  program  segments: 

IF  Cl  THEN  DO; 

SI; 

IF  C2  THEN  DO; 

S2; 

L:  S3; 

END; 

ELSE  S5 ; 

END; 

ELSE  DO; 

S4; 

GO  TO  L; 

END; 

for  the  unstructured  flowchart  and 
IF  Cl  THEN  DO; 

SI; 

IF  C2  THEN  DO; 

S2; 

S3; 

END; 

ELSE  S5 ; 

END; 

ELSE  DO; 

S4; 

S3; 

END; 
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FIG.  13(a)  THE  "1"  ELEMENT 


FIG.  13(b)  THE  "x"  ELEMENT 


FIG.  13  BASIC  ELEMENTS  OF  A  FLOWCHART 


FIG.  14  AN  X2  +  3x  +  2  CONNECTION  REALIZED  BY  SERIES 
SEQUENCE  OF  x+1  AND  x+2 
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FIG.  15 


FIG.  16 


AN  x2 
AND  1 


+  1  CONNECTION  REALIZED  BY  PARALLELING  x2 


AN  x2  +  X  CONNECTION  REALIZED  BY  PARALLELING  x2 
AND  x 
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for  the  structured  flowchart.  Intuitively,  these  two  segments  have  the  same 
complexity  and  are  both  described  by  the  same  polynomial.  The  inspection 
of  the  last  flowchart  of  Fig.  18  reveals  it  to  be  a  parallel  connection  of  x 
and  1,  giving  x+1  for  the  polynomial. 

As  a  second  example  consider  the  following  PL/I  program  segment,  illus¬ 
trating  how  to  evaluate  the  complexity  of  an  unstructed  code. 

IF  A=B  THEN  GO  TO  LI; 

GO  TO  NO; 

LI:  IF  A=C  THEN  GO  TO  L2; 

GO  TO  NO; 

L2 :  PUT  LIST  ('SUCCESS'); 

GO  TO  L3 ; 

NO:  PUT  LIST  ('FAILURE'); 

L3 : 

This  fragment  is  flowcharted  in  Fig.  19.  Transformation  to  a  struc¬ 
tured  program,  shown  in  Fig.  20,  shows  it  again  to  be  a  parallel  connection 
of  x  and  1  yielding,  as  before,  the  x+1  polynomial. 

As  a  third  example,  consider  the  flowchart  of  Fig.  21.  As  before,  we 
want  to  obtain  its  polynomial.  The  simplified  flowchart  and  its  conversion  to 
a  structured  form  are  shown  in  Fig.  22.  The  polynomial  is  obtained  from 
paralleling  x+1  and  x  resulting  in  2x+l.  The  structured  flowchart,  equiva¬ 
lent  to  the  one  of  Fig.  21,  is  shown  in  Fig.  23. 

Incidentally,  it  may  be  of  interest  to  contrast  the  programs  for  the  two 
flowcharts  of  Fig.  21  and  23.  For  Fig.  21  the  program  segment  (in  PL/I) 
is: 

IF  A  THEN  DO; 

SI; 

GO  TO  L; 

END; 

ELSE  IF  B  THEN  S2; 

ELSE  L:  IF  C  THEN  S3; 

ELSE  S4  ; 

while  for  Fig.  23  we  obtain: 

IF  A  THEN  DO; 

SI; 

IF  C  THEN  S3; 

ELSE  S4; 

END; 

ELSE  IF  B  THEN  S2; 

ELSE  IF  C  THEN  S3; 

ELSE  S4; 

which  are  intuitively  of  same  complexity,  as  asserted. 

We  have  just  illustrated  how  to  obtain  the  polynomial  measure  of  com¬ 
plexly  of  a  structured  or  unstructured  flowchart  containing  just  sequential 
statements  and  deciders.  We  shall  next  treat  flowcharts  containing  loops  and 
CASE  statements. 
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FIG.  19  FLOWCHART  FOR  THE  PROGRAM  SEGMENT  OF  THE  SECOND 
EXAMPLE 


THE  UNSTRUCTURED  FL 
CTURED  ONE 


FIG.  22 


SIMPLIFIED  FLOWCHART  AND  ITS  CONVERSION 
STRUCTURED  FORM 


FIG.  23  A  FLOWCHART  EQUIVALENT  TO  THE  ONE  OF  FIG.  21 


7.0  REPRESENTATION  OF  LOOPS 

Even  though  any  program  can  be  constructed  with  just  sequences  and 
deciders,  such  a  construction  is  awkward  without  loops.  Consequently,  let 
us  consider  the  effect  of  a  loop  on  the  polynomial  measure  p(x). 

The  basic  representation  of  a  loop  is  through  the  DOWHILE  element 
shown  in  Fig.  24.  We  want  to  convert  by  geometric  manipulations  a  flow¬ 
chart  with  loops  into  a  loopless  one.  Such  a  manipulation  has  been  sug¬ 
gested  by  Shooman  [13]  and  involves  node  splitting  as  portrayed  in  Fig.  25. 
Since  the  last  flowchart  in  Fig.  25(c)  is  the  parallel  connection  of  x  and  1, 
it  (and  thus  the  loop)  is  described  by  x+1. 

The  justification  for  this  manipulation  lies  in  the  practice  of  testing  a 
loop  just  twice,  once  for  the  initial  value  (of  the  control  variable  or  control 
expression),  and  then  again  for  the  final  value  (i.e.,  the  value  of  the  con¬ 
trol  variable  just  before  exit).  Such  a  reduction  in  testing  is  commonplace 
to  reduce  both  the  volume  of  test  data  (which  has  to  be  studied)  and  the 
testing  cost.  For  example,  the  loop: 

I  =  1; 

DO  WHILE  (I<=1000) ; 

f; 

1=1+1; 

END; 

may  in  practice  be  tested  by: 

I  =  1; 

DO  WHILE  (K1000); 

f; 

I  =  1+999; 

END; 

Another  viewpoint  also  leads  to  same  conclusion.  A  loop  such  as  the 
one  in  Fig.  26(a)  converts  generally  into  many  deciders  which  are  in  turn 
approximated  by  just  two  deciders,  as  shown  in  Fig.  26(c).  This  is  justified 
by  viewing  two  loops  each  with  the  same  initial  value  and  body,  but  with  a 
different  final  value  as  for  example, 

DO  I  =  1  TO  2; 

f; 

END; 

and: 

DO  I  =  1  TO  1000; 

f; 

END; 

as  being  of  equal  complexity,  because  they  both  require  the  same  testing 
effort. 

We  have  just  established  that  a  loop  is  described  by  x+1 .  Since  loops 
can  be  either  consecutive  or  nested,  let  us  next  obtain  the  polynomials  for 
both  these  situations. 


FIG.  24  THE  DOWHILE  ELEMENT 


(This  element  portrays  the  program  segment 
Statement; 

DO  WHILE  (p); 

f; 

END;  ) 


(a)  ORIGINAL 
LOOP 


(b)  SPLITTING 
THE  NODE 


(c)  EQUIVALENT 
LOOPLESS 
FLOWCHART 


FIG.  25  THE  CONVERSION  OF  LOOP  TO  AN  EQUIVALENT  LOOPLESS 
FLOWCHART 
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(a)  THE  (b)  COMPLETE 

ORIGINAL  CONVERSION 

LOOP 


(C)  REDUCED 

CONVERSION 
(described  by 
x+1) 


FIG  26  REDUCED  CONVERSION  OF  A  LOOP 


(a)  TWO  CONSECUTIVE  LOOPS  (b)  EQUIVALENT  FLOWCHART 

FIG.  27  TWO  CONSECUTIVE  LOOPS  AND  THEIR  EQUIVALENT  FLOW¬ 
CHART 
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Two  consecutive  loops  are  shown  in  Fig.  27(a).  Since  each  loop  is  de¬ 
scribed  by  x+1  and  this  is  a  sequential  connection  of  two  such  x+1  poly¬ 
nomials,  the  polynomial  for  both  these  loops  is  (x+1)2  (see  Fig.  12).  More 

generally,  n  consecutive  loops  results  in  the  (x+l)n  polynomial. 

When  a  loop  is  nested  within  another,  we  have  the  situation  portrayed 
in  -L.g.  28(a).  As  before,  the  nested  inner  loop  may  be  replaced  by  x+1, 
(that  is,  its  polynomial),  resulting  in  the  flowchart  of  Fig.  28(b).  But  this 
flowchart  is  the  same  as  the  one  of  Fig.  26(a),  with  f  being  replaced  by 
x+1,  as  shown  in  Fig.  28(c).  This  leads  to  the  polynomial  p2(x)  for  the 
nesting  of  2  loops  as 

p2(x)  =  [(x+1)  +  1]  (x+1)  +  1  =  (x+2)(x+l)  +  1 

polynomial 
for  the  first 
decider 


Again  we  can  generalize  to  a  nesting  of  n  loops  and  obtain  Pn(x)  = 
[pn  ^(x)  +  1J  pn_^(x)  +  1.  Specific  examples  for  n=2,3,  and  4  are 

p2(x)  =  x2  +  3x  +  3 

p3(x)  =  (x2+3x+4 )(x2+3x+3 )  +  1  =  x4+6x3+16x2+21x+13 

P4(x)  =  (x4+6x3+16x2+21x+14)(x4+6x3+16x2+21x+13)  +  1 

Observe  how  quickly  the  polynomial  grows  with  levels  of  nesting  indi¬ 
cating  the  rapid  increase  in  complexity. 

We  have  just  described  how  to  trerat  loops.  We  shall  next  consider  the 
multiple  selectors  (i.e.,  the  CASE  statement). 

8.0  THE  CASE  STATEMENT 

Figure  29(a)  portrays  a  multiple  selector  implementable  by  the  CASE 
statement  with  3  cases.  Using  the  node  splitting  technique  as  in  Fig.  25, 
we  obtain  the  equivalent  flowchart  of  Fig.  29(b).  This  last  flowchart  is  a 
parallel  connection  of  the  x  and  1  elements,  yielding  x+1.  More  generally  a 
CASE  statement  with  n+2  cases  is  described  by  x+n. 

We  have  just  shown  how  to  characterize  a  flowchart  by  a  polynomial. 
We  shall  next  consider  the  topic  of  equivalent  flowcharts. 

9.0  EQUIVALENT  FLOWCHARTS 

9.1  Definition  and  Examples 

We  will  consider  two  flowcharts  to  be  equivalent  if  they  are  character¬ 
ized  by  the  same  polynomial.  Because  a  polynomial  can  generally  be  parti¬ 
tioned  into  simpler  terms  in  several  ways,  the  different  realizations  lead  to 
equivalent  flowcharts. 
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(a)  A  NESTED 
LOOP 


(b)  REPLACEMENT 
OF  THE  INNER 
LOOP  BY  x+1 


(c)  EQUIVALENT 
FLOWCHART 


FIG.  28  A  NESTED  LOOP  AND  ITS  EQUIVALENT  FLOWCHART 


(a)  A  MULTIPLE  SELECTOR 


(b)  EQUIVALENT  FLOWCHART 


FIG.  29  A  MULTIPLE  SELECTOR  AND  ITS  EQUIVALENT  FLOWCHART 
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To  illustrate  different  realizations  consider  Fig.  6,  portraying  the  x2+x 
connection.  In  Fig.  6  the  bottom  part  represents  x+1  and  the  top  decider 
an  x  multiplier,  resulting  in  x(x+l)  or  x2+x.  It  is  also  possible  to  realize 
x2+x  by  paralleling  x2  and  x,  as  shown  in  Fig.  30.  Note  that  the  first 
(i.e.,  top)  decider  separates  x2  form  x. 

Observe  that  the  flowchart  of  Fig.  30  has  one  more  decider  than  the 
flowchart  of  Fig.  6.  Comparing  the  program  segment  for  Fig.  30,  that  is, 

IF  A  THEN  IF  B  THEN  SI; 

ELSE  S2; 

ELSE  DO; 

IF  C  THEN  S3; 

ELSE  S4 ; 

IF  D  THEN  S5; 

ELSE  S6  ; 

END; 

with  the  program  segment  for  Fig.  6,  i.e., 

IF  A  THEN  SI; 

ELSE  S2 ; 

IF  B  THEN  IF  C  THEN  S3; 

ELSE  S4; 

ELSE  S5; 

We  ask  whether  the  definition  agrees  with  our  intuitive  notion  of  com¬ 
plexity.  If  analyzing  the  first  segment  (for  Fig.  30),  we  deduce  that: 

51  is  executed  for  AB 

52  is  executed  for  AB 

53  and  S5  are  executed  for  ACD 

53  and  S6  are  executed  for  ACD 

54  and  S5  are  executed  for  ACD 
S4  and  S6  are  executed  for  ACD 

The  analysis  of  the  second  segment  (for  Fig.  6)  tells  that: 


SI 

and 

S3 

are 

executed 

for 

ABC 

SI 

and 

S4 

are 

executed 

for 

ABC 

SI 

and 

S5 

are 

executed 

for 

AB 

S2 

and 

S3 

are 

executed 

for 

ABC 

S2 

and 

S4 

are 

executed 

for 

ABC 

S2 

and 

S5 

are 

executed 

for 

AB 
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which  indicates  the  same  testing  is  needed  to  verify  it  as  the  first  segment, 
and  thus  intuitively  of  the  same  complexity  as  the  first  segments. 

An  additional  example  of  equivalent  flowcharts  is  shown  in  Figs.  31  and 
32.  In  Fig.  31  x2+2x+3  is  realized  as  an  additive  connection  of  x2,  x,  and 
x+3.  We  shall  call  such  a  partitioning  of  a  polynomial  as  "additive"  parti¬ 
tioning.  In  Fig.  32  x  multiplies  x+2  and  then  3  is  added.  We  shall  call  this 
second  type  of  partitioning  "multiplicative"  partitioning.  The  analysis  of 
program  segments  arising  from  both  constructions  leads  to  the  conclusion 
that  both  will  require  the  same  testing  effort  and  thus  have  the  same  com¬ 
plexity  (see  Appendix). 

9.2  Realization  of  the  Polynomial  with  Fewest  Deciders 

It  is  evident  from  the  last  2  examples  that  additive  partitioning  leads  to 
a  realization  with  more  deciders  than  does  multiplicative  partitioning.  As  an 
example  consider  the  different  realizations  of  x3+3x2+x+2. 

1.  Additive  partitioning: 
x3  requires  3  deciders 

3x2  requires  3*2+2=8  deciders  (2  extra  deciders  needed  to  add 
x2+x2+x2) 

x  requires  1  decider 

. ' .  x3+3x2+x  requires  16  deciders  (2  additional  deciders  for  the  2 
additions) 

and  finally 

x3+3x2+x+2  requires  16  deciders  (2  deciders  for  +2) 

2 

2.  x  (x+3)  +  (x+2)  partitioning 
x2  requires  2  deciders 

x+3  requires  4  deciders 

x2(x+3)  requires  6  deciders 

x+2  requires  3  deciders 

x2(x+3)  +  (x+2)  requires  10  deciders  (one  additional  decider 
for  the  addition). 

3.  x(x(x+3)+l)  +  2  partitioning 
x+3  requires  4  deciders 

x(x+3)  requires  5  deciders 

x(x+3)+l  requires  6  deciders 

x(x(x+3)+l)  requires  7  deciders 

x(x(x+3)+l)+2  requires  9  deciders 


AS  A  SUM  OF  (x2)+(x)+(x+3) 


X  +  2 

FIG.  32  x2+2x+3  REALIZED  AS  x(x+2)+3 


L 
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From  this  example  it  can  be  deduced  that  a  minimal  decider  realization 
of  a  polynomial  will  be  obtained  if  the  polynomial  is  expressed  in  the  "nested 
from"  as  in  the  last  partitioning.  This  is  so  because  no  extra  deciders  are 
needed  for  addition.  Then  for  the  general  cubic  polynomial 

a3x3  +  a2x2  +  axx  +  a0  =  a0+x(a1+x(a2+a3x)) 

(where  obviously  all  a.  are  non-negative  integers)  we  need 

2a3-l  deciders  for  a3x  (one  decider  for  each  of  the  a3  x  and  a3-l 
deciders  for  their  additions) 

a2+2a3-l  deciders  for  a2+a3x 

a2+2a3  deciders  for  x(a2+a3x) 

ax+a2+2a3  deciders  for  a!+x(a2+a3x) 

a1+a2+2a3+l  deciders  for  x(ax+x(a2+a3x)) 

a0+a1+a2+2a3+l  deciders  for  the  polynomial 

This  result  can  be  generalized  with  the  theorem 

Theorem 


The  minimal  decider  realization  of  the  polynomial 


P(x) 


n 

I 

k=0 


akx 


k 


requires 


n-1  +  2a 

n 


n-1  n-1 

1  +  I  ak  =  n-2  +  2a  +  I  a 
k=0  K  n  k=0 


(9-1) 


deciders.  This  realization  is  achieved  with  the  polynomial  expressed  in  the 
so  called  "nested  form." 


9.3  The  Deciders  Needed  for  Additive  Partitioning 

We  have  just  determined  the  lower  bound  on  deciders  realizing  a  poly¬ 
nomial.  Let  us  now  determine  the  number  of  deciders  needed  for  additive 
partitioning.  This  will  give  us  an  upper  bound  on  the  deciders.  Consider 
again  the  polynomial  a3x  +  a2x2  +  ax  +  a0- 

a3x3  requires  4a3  -  1  deciders  (a3  -  1  deciders  needed  for  the 
additions 
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a2x2  requires  3a2-l  deciders 
ajX  requires  2ax  -  1  deciders 

a3X3+a2x2+a!X  requires  4a3+3a2+2axx-l  deciders  (2  additional  de¬ 
ciders  needed  for  the  2  additions) 

a3x3+a2x2+a1+a0  requires  4a3+3a2+2a1+a0-l  deciders. 

Thus  in  general,  the  additive  realization  of  the  polynomial 

n  k 
p(x)  =  2  a.x 

k=0  K 

requires : 


n 

I  (k+l)a.  -  1  (9.2) 

k=0  K 


deciders.  This  is  the  upper  bound  on  the  deciders. 

From  the  results  of  (9.1)  and  (9.2)  it  follows  that  a  polynomial  p(x) 
may  be  realized  with  n  deciders  where 


n-1  n 

n-2  +  2a  +  I  a.  <  n  <  I  (k+1)  a,  -  1 
n  k=0  K  k=0  K 

10.0  APPLICATIONS  OF  THE  MEASURE 
10.1  Cyclomatic  Complexity 

The  cyclomatic  complexity  [2]  of  a  single  flowchart  (i.e.,  p=l,  meaning 
that  the  program  has  no  procedures)  was  given  as  n+1,  where  n  is  the  num¬ 
ber  of  deciders.  From  the  preceeding  section  we  have  a  bound  on  n.  Con¬ 
sequently,  a  flowchart  characterized  by  the  polynomial  p(x)  has  the  cyclo¬ 
matic  complexity  V  bounded  by 

n-1  n 

n-1  +  2a+  I  9i,  1  V  <  I  (k+l)a, 
n  k=0  K  k=0  K 


As  an  example,  the  flowchart  described  by 
p(x)  =  3x2  +  2x  +  1 

has  the  cyclomatic  complexity  V  bounded  by 

2-1  +  2*3  +  2+1  <  V  <  3-3  +  2-2  +  1 


or 


10  <  V  <  14 
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10.2  Number  of  Program  Paths 

One  of  the  usual  tests  of  a  program  is  the  type  2  test  [14].  In  such 
test  each  program  path  is  executed  at  least  once.  A  measure  of  extent  of 
such  a  test  (and  thus  of  test  effort)  is  the  number  of  program  paths,  which 
is  given  by 

Number  of  program  paths  =  p(2) 

To  see  that  this  is  so,  consider  first  the  two  basic  connections  of  two 
flowcharts,  parallel  and  sequential.  For  the  parallel  connection  (shown  in 
Fig.  11)  the  paths  just  add,  hence 

Total  number  of  paths  =  paths  in  the  flowchart  described  by  pj(x) 
+  paths  in  the  flowchart  described  by  p2(x). 

For  the  sequential  connection  (shown  in  Fig.  12),  the  paths  multiply.  This 
can  be  noted  from  Fig.  33,  hence, 

Total  number  of  paths  =  (paths  in  the  flowchart  described  by 
Pi(x))  (paths  in  the  flowchart  described  by  p2(x)). 

Since  all  flowcharts  are  comprised  by  either  parallel  or  sequential  con¬ 
nection  of  the  two  basic  elements,  the  "l",  (which  has  1  path)  and  "x" 
(which  has  2  paths)  shown  in  Fig.  13,  the  total  number  of  program  paths  of 
a  flowchart  described  by  p(x)  is  indeed  p(2). 

11.0  MODULAR  PROGRAMS 

The  principal  tool  in  the  design  of  large  software  system  is  to  divide 
the  system  into  smaller  units.  Such  a  division  intuitively  reduces  the  overall 
complexity  by  allowing  us  to  deal  with  smaller,  less  complex  "modules."  Two 
questions  may  be  posed: 

1.  What  effect  has  the  modular  division  on  the  polynomial  complexity? 

and 

2.  What  is  the  optimum  division,  that,  how  should  the  program  be 
divided? 

Let  us  consider  the  first  question.  Evidently,  a  program  with  a  single 
procedure  is  represented  by  a  single  flowchart,  leading  to  a  single  poly¬ 
nomial.  Similarly,  a  modular  program  consists  of  several  procedures  (one  for 
each  module),  with  each  procedure  represented  by  a  separate  flowchart. 
Each  flowchart  is  characterized  by  its  own  polynomial.  The  entire  modular 
program  is  the  sum  of  the  individual  polynomials.  Thus,  for  a  modular 
program  with  n  modules, 

n 

p(x)  =  I  p.(x) 
i=l  1 

where  p.(x)  is  the  polynomial  characterizing  the  flowchart  for  the  ith 
module . 
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M  PATHS 

[FLOWCHART  DESCRIBED  BY 
Pi(x)] 


N  PATHS 

[FLOWCHART  DESCRIBED  BY 

P2(x)] 


FIG.  33  SEQUENTIAL  CONNECTION  OF  TWO  FLOWCHARTS,  SHOWING  M-N 
TOTAL  PATHS 


As  an  example,  consider  the  flowchart  of  Fig.  32,  with  the  decider 
labeled  x  removed  to  a  separate  flowchart.  This  situation  is  shown  in  Fig. 
34.  Fig.  34(a)  is  characterized  by  (x+2)+3  or  x+5.  Fig.  15(b)  is  character¬ 
ized  by  x.  Hence,  the  entire  modular  program  is  characterized  by  x+5+x  or 
2x+5,  which  results  in  a  polynomial  of  lower  complexity  than  the  one  charac¬ 
terizing  the  single  flowchart  of  Fig.  32. 

Consider  next  the  flowchart  of  Fig.  31.  We  will  now  replace  the  two 
deciders  labeled  x2  by  a  single  module.  This  results  in  the  two  flowcharts 
portrayed  in  Fig.  35.  The  polynomial  describing  the  flowchart  of  Fig.  35(a) 
is  (x+l)+(x+3)  or  2x+4.  The  module  is  represented  by  x2.  Hence,  the  en¬ 
tire  modular  program  is  characterized  by  x2+2x+4  which  is  certainly  not  sim¬ 
pler  than  the  original  polynomial  x2+2x+3. 

The  observation  of  these  two  examples  leads  to  the  following  conclusions: 

1.  In  the  first  example  a  multiplicative  part  was  replaced  by  a  mod¬ 
ule.  This  had  the  effect  of  replacing  a  multiplicative  part  by  an 
additive  part.  In  general,  if  the  original  polynomial  p0(x)  can  be 
decomposed  into 

Po(x)  =  Pi(x)  p2(x)  +  p3(x) 

and  p2(x)  is  replaced  by  a  module,  the  new  characterization  p  (x) 
becomes  n 

Pn(x)  =  Pi(x)  +  p3(x)  +  p2(x) 

which  leads  to  a  polynomial  of  a  lower  degree  and  thus  lower  com¬ 
plexity  . 

2.  In  the  second  example  an  additive  component  was  replaced  by  a 
module.  If  the  original  polynomial  p0(x)  =  p^x)  +  p2(x),  we  will 

let  p2(x)  be  replaced  by  a  module.  This  results  in  two  flowcharts, 

one  characterized  by  pj(x)+l  and  the  other  by  p2(x),  resulting  in 

the  new  overall  characterization  of 

Pn(x)  =  Px(x)  +  P2(x)  +  1 

and  thus  of  no  lower  complexity  than  the  original  polynomial 
Po(x). 

The  above  answers  the  first  question  posed  in  the  beginning  of  this 
section,  by  showing  the  two  possible  effects  of  modular  division  on  poly¬ 
nomial  complexity.  It  also  allows  to  answer  the  second  question,  asking  how 
modules  are  to  be  chosen.  The  answer  is  that  multiplicative  terms  should  be 
replaced  by  modules,  because  such  modularization  lowers  the  degree  of  the 
polynomial  p(x).  The  replacement  of  additive  terms  by  modules  is  not  rec¬ 
ommended  because  such  modularization  does  not  lead  to  lower  complexity. 
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FIG.  34(B)  FLOWCHART  REPRESENTING  x 

FIG.  34  FLOWCHART  OF  FIG.  32  WITH  THE  MODULE  X  SHOWN 
SEPARATELY 


FIG.  35  (B)  FLOWCHART  REPRESENTING  x2 

FIG.  35  FLOWCHART  OF  FIG.  31,  WITH  THE  MODULE  x2  SHOWN 
SEPARATELY 
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In  Section  9.0  we  described  the  construction  of  a  flowchart  from  the 
polynomial  p(x).  The  construction  methods  given  there  resulted  in  a  single 
flowchart.  Observe  that  modular  realizations  give  rise  to  additional  con¬ 
struction  techniques.  The  development  of  such  techniques  is  left  to  the 
future. 

12.0  ASSESSMENT  OF  THE  POLYNOMIAL  COMPLEXITY  MEASURE 

A  question  of  interest  is:  "How  does  the  polynomial  measure  compare 
with  the  other  measures  in  predicting  program  complexity?"  To  answer  this 
question,  seven  exercises  were  selected  from  a  textbook  on  programming 
[15].  For  each  of  these,  a  program  was  constructed,  debugged,  and  tested, 
and  the  completion  time  and  number  of  statements  were  recorded.  The  sim¬ 
plified  flowcharts  were  then  drawn  for  the  programs,  and  are  shown  in  Fig. 
36.  A  number  n  inside  a  decider  indicates  a  decider  with  n  conditions  (and 
no  number  indicates  a  single  condition).  The  names  P13  IB,  P13  1A,  and  so 
on,  are  the  ■  names  of  the  programs  (and  the  exercises)  The  results  are 
tabulated  in  Table  1  and  include  the  average  number  of  minutes  -  x^ended  on 
each  statement  and  the  four  complexity  measures:  the  cyrlomatu-  extended 
(Myers,  [8]),  MIN,  and  polynomial.  The  MIN  measure  is  only  .lefined  for 
loopless  flowcharts,  thus,  only  the  first  3  programs  show  this  measuie.  Th- 
other  control  flow  complexity  measures  are  not  shown  because  the  programs 
written  for  the  seven  exercises  were  in  PL/I,  and  hence  did  not  contain  the 
CASE  statement.  Thus  the  third  and  fourth  variations  of  Basili  and  Reiter 
[9]  were  of  no  interest.  (The  first  and  second  variations  are  the  cyclomatic 
and  the  second  number  of  the  extended,  respectively.)  The  knots  are  not 
shown  because  all  programs  are  structured  and  hence  have  no  knots. 

The  table  demonstrates  that  polynomial  complexity  correlates  with  thy 
effort  expended  on  each  statement,  and  does  so  better  than  the  other  meas¬ 
ure  (or  the  number  of  paths).  It  is  interesting  to  note  that  the  fifth  degree 
polynomial  with  two  terms  in  P131C  ]eads  to  a  lower  "complexity"  than  the 
fourth  degree  polynomial  with  all  five  terms  in  P9_5. 

13.0  SUMMARY 

A  new  measure  of  complexity  was  introduced,  one  which  considers  de¬ 
ciders  and  the  way  they  are  connected.  The  measure  is  unique  and  inter¬ 
prets  a  program  flowchart  through  a  polynomial.  It  was  shown  that  the 
measure  yields  a  bound  on  cyclomatic  complexity,  and  the  expected  number 
of  path  tests.  The  measure  allows  the  comparison  of  alternate  designs  and 
the  choice  of  the  design  of  minimal  complexity.  A  further  advantage  of  the 
measure  is  its  application  to  modular  designs;  the  measure  tells  which  modu¬ 
larization  contributes  to  a  reduction  in  over  complexity. 

The  report  concludes  with  a  comparison  between  the  polynomial  measure 
and  several  other  popular  measures. 
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APPENDIX 


We  will  consider  two  different  flowcharts,  characterized  by  the  same 
polynomial  and  investigate  their  complexities.  We  will  use  to  this  end  the 
flowcharts  of  Figures  31  and  32,  redrawn  with  more  detail  in  Figures  A.l 
and  A. 2. 

The  program  segment  describing  Fig.  A.l  is 

IF  A  THEN  IF  B  THEN  IF  C  THEN  IF  D  THEN  IF  E  THEN  SI; 

ELSE  S2 ; 

ELSE  S3; 

ELSE  S4; 

ELSE  S5 ; 

ELSE  IF  F  THEN  IF  G  THEN  S6; 

ELSE  S7 ; 

ELSE  DO; 

IF  H  THEN  S8; 

ELSE  S9 ; 

IF  I  THEN  S10; 

ELSE  Sll ; 

END; 

The  flowchart  of  Fig.  A. 2  is  described  by 


IF  A  THEN  SI; 

ELSE  IF  B  THEN  S2; 

ELSE  IF  C  THEN  S3; 

ELSE  DO; 

IF  D  THEN  S4 ; 

ELSE  S5; 
IF  E  THEN 
IF  F  THEN  IF  G  THEN  S6; 

ELSE  S7 ; 

ELSE  S8; 

ELSE  S9; 


END; 


To  compare  the  complexities  of  these  two  program  segments  we  will  con¬ 
sider  the  conditions  and  the  resulting  executions . 
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IF  A  THEN  SI; 

ELSE  IF  B  THEN  S2; 

ELSE  IF  C  THEN  S3; 

ELSE  DO; 

IF  D  THEN  S4  ; 

ELSE  S5 ; 
IF  E  THEN 
IF  F  THEN  IF  G  THEN  S6; 

ELSE  S7 ; 

ELSE  S8; 


ELSE  S9; 

END; 


To  compare  the  complexities  of  these  two  program  segments  we  will  con¬ 
sider  the  conditions  and  the  resulting  executions. 
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which  leads  to  the  following  observations: 

1.  Both  flowcharts  result  in  the  same  number  of  distinct  actions  (this 
being  11  for  both  flowcharts). 

2.  The  flowchart  of  Fig.  A.l  is  realized  with  13  statements,  the  flow¬ 
chart  of  Fig.  A. 2  with  11  statements. 

3.  The  total  number  of  individual  conditions  to  be  satisfied  for  the 
execution  of  the  11  distinct  actions  in  Fig.  A.l  is  41  or  41/11  = 
3.73  average  conditions/actions.  To  execute  the  11  actions  in  Fig. 
A. 2  we  must  satisfy  a  total  of  56  individual  conditions,  or  56/11  = 
5.09  average  conditions/actions . 

This  leads  to  the  conclusion  that  from  the  first  observation  both  flow¬ 
charts  have  the  same  complexity.  The  second  observation  tells  that  the 
flowchart  of  Fig.  A.l  requires  a  program  segment  1890  fi  e.,  (13-li)*100/ll] 
longer  than  the  flowchart  of  Fig.  A. 2.  The  third  observation  tells  that  the 
testing  of  all  actions  will  require  1.36  (i.e.,  5.09-3.73)  more  conditions  per 
action.  Thus,  Fig.  A.l  is  more  complex  than  Fig.  A. 2  from  one  viewpoint 
and  less  complex  from  another  viewpoint,  but  equally  complex  from  the  im¬ 
portant  comparison  of  distinct  actions.  The  overall  conclusion  is  then  that 
both  flowcharts  exhibit  the  same  complexity. 
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